home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / cstd.arc / CSTD7#4 < prev    next >
Encoding:
Text File  |  1985-07-28  |  14.9 KB  |  409 lines
  1. /* ---------- "mod.std.c Digest V7#4" ---------- */
  2. From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
  3.  
  4.  
  5. mod.std.c Digest            Mon, 24 Jun 85       Volume 7 : Issue   4 
  6.  
  7. Today's Topics:
  8.                        Section A.7 (Compliance)
  9.                    Section B.2.2 (alert character)
  10.                    Section C.1.3.2 (integer suffix)
  11.                        Section C.1.7 (comments)
  12.                  Section C.3 (grouping of operations)
  13.                        Section C.3.3.4 (sizeof)
  14.                      Section C.5.2 type-specifier
  15.              Section C.8 (preprocessing directives start)
  16.                     Section C.8.3 (#if and #elif)
  17.          Section C.8.3 (comments on preprocessor directives)
  18.       Section C.8.3 (preprocessor directives order of checking)
  19.             Section C.8.6 ('null' preprocessor directive)
  20.            Section D.1.2 (external identifiers on headers)
  21.                  Section D.9.5.6 ( printf arguments)
  22.                                volatile
  23. ----------------------------------------------------------------------
  24.  
  25. Date: Thu, 20 Jun 85 15:43:57 EDT
  26. From: seismo!elsie!ado
  27. Subject: Section A.7 (Compliance)
  28. To: std-c@cbosgd
  29.  
  30. *       Section A.7, page 3:
  31.  
  32.                 Strictly conforming programs are intended to be maximally
  33.                 portable.
  34.  
  35.         Given that "strictly conforming programs" can be written that won't
  36.         run on any existing implementations, delete the above sentence--
  37.         or change it to something like:
  38.  
  39.                 Strictly conforming programs are intended to be maximally
  40.                 portable among different conforming hosted implementations.
  41.  
  42. ------------------------------
  43.  
  44. Date: Thu, 20 Jun 85 15:43:57 EDT
  45. From: seismo!elsie!ado
  46. Subject: Section B.2.2 (alert character)
  47. To: std-c@cbosgd
  48.  
  49. *       Section B.2.2, page 9:
  50.  
  51.                 \a      (alert) Produces an implementation-defined. . .alert
  52.                         character.  Any consequent alteration to the printing
  53.                         position is implementation-defined.
  54.  
  55.         First, change the second sentence to read "The printing position
  56.         is left as is."
  57.  
  58.         Second, change the alert escape to \!, to allow for graceful degradation
  59.         of programs shipped to "old" (that is, current) systems--doing a
  60.                 printf("Wake up\!\n");
  61.         would produce
  62.                 Wake up
  63.         followed by an alert character on conforming hosted implementations,
  64.         and would produce
  65.                 Wake up!
  66.         on current systems.
  67.  
  68. ------------------------------
  69.  
  70. Date: Thu, 20 Jun 85 15:43:57 EDT
  71. From: seismo!elsie!ado
  72. Subject: Section C.1.3.2 (integer suffix)
  73. To: std-c@cbosgd
  74.  
  75. *       Section C.1.3.2, page 18:
  76.  
  77.                 integer-suffix:
  78.                         integer-suffix-letter
  79.                         integer-suffix-letter integer-suffix-letter
  80.  
  81.                 integer-suffix-letter:  one of
  82.                         u l U L
  83.  
  84.         By this definition,
  85.  
  86.                         0uu
  87.  
  88.         is a (very unsigned?) integer constant.  If this is the standard's
  89.         intent, fine; otherwise, go back to the definition of
  90.         integer-suffix used in the November, 1984 draft.
  91.  
  92. ------------------------------
  93.  
  94. Date: Thu, 20 Jun 85 15:43:57 EDT
  95. From: seismo!elsie!ado
  96. Subject: Section C.1.7 (comments)
  97. To: std-c@cbosgd
  98.  
  99. *       Section C.1.7, page 22:
  100.  
  101.                 The contents of a comment are examined only to find the
  102.                 characters */ that terminate it.  Thus comments do not nest.
  103.  
  104.         and section E.3, page 135, listing "common warnings":
  105.  
  106.                 The characters /* are found in a comment.
  107.  
  108.         Sorry. . .if you're only allowed to look for the */ that terminates
  109.         a comment, you can't look for a /*.  Change the first quote to:
  110.  
  111.                 The contents of a comment are examined to find the characters
  112.                 */ that terminate it.  Comments do not nest.
  113.  
  114. ------------------------------
  115.  
  116. Date: Thu, 20 Jun 85 15:43:57 EDT
  117. From: seismo!elsie!ado
  118. Subject: Section C.3 (grouping of operations)
  119. To: std-c@cbosgd
  120.  
  121. *       Section C.3, page 26:
  122.  
  123.                 To force a particular grouping of operations, either the value
  124.                 of an expression to be grouped may be explicitly assigned to
  125.                 an object, or grouping parentheses may be preceded by a unary
  126.                 plus or minus operator.
  127.  
  128.         and section C.3.3.3, page 31:
  129.  
  130.                 . . .Except that it inhibits regrouping, the expression +E
  131.                 is equivalent to (0+E).
  132.  
  133.                 . . .The expression -E is equivalent to (0-E).
  134.  
  135.         The first quote indicates that with respect to inhibiting regrouping,
  136.         unary plus and unary minus are the same, so the last quotes should
  137.         be either:
  138.  
  139.                 . . .The expression +E is equivalent to (0+E).
  140.  
  141.                 . . .The expression -E is equivalent to (0-E).
  142.         or:
  143.                 . . .Except that it inhibits regrouping, the expression +E
  144.                 is equivalent to (0+E).
  145.  
  146.                 . . .Except that it inhibits regrouping, the expression -E
  147.                 is equivalent to (0-E).
  148.  
  149. ------------------------------
  150.  
  151. Date: Thu, 20 Jun 85 15:43:57 EDT
  152. From: seismo!elsie!ado
  153. Subject: Section C.3.3.4 (sizeof)
  154. To: std-c@cbosgd
  155.  
  156. *       Section C.3.3.4, page 32:
  157.  
  158.                 Another use of the sizeof operator is to compute the number of
  159.                 members in an array:
  160.                         sizeof(array)/sizeof(array[0])
  161.  
  162.         The parentheses can be dispensed with here--and I think it's a good
  163.         idea to dispense with them, to ensure that implementors get the idea
  164.         that parentheses are optional when sizeof is applied to a
  165.         unary-expression.  Change the example to read:
  166.  
  167.                         sizeof array / sizeof array[0]
  168.  
  169. ------------------------------
  170.  
  171. Date: Thu, 20 Jun 85 15:43:57 EDT
  172. From: seismo!elsie!ado
  173. Subject: Section C.5.2 type-specifier
  174. To: std-c@cbosgd
  175.  
  176. *       Section C.5.2, page 42:
  177.  
  178.                 type-specifier:
  179.                         ...
  180.                         const
  181.                         volatile
  182.  
  183.         Change to:
  184.  
  185.                 type-specifier:
  186.                         ...
  187.                         constant
  188.                         volatile
  189.  
  190.         and change all other references to the keyword "const".  I've noted
  191.         before that I like seeing things spelled out in full.  A new note:
  192.         using "constant" rather than "const" is less likely to break existing
  193.         code, since it is a longer word, is therefore more likely to break
  194.         identifier-length limits in existing systems, and is therefore less
  195.         likely to appear as an identifier in existing programs.
  196.  
  197. [ This I heard, it is likely that more existing programs abound with 
  198. 'constant' as an identifier name than 'const'. On the other hand, nobody
  199. has found 'volatile' used as an identifier name.     -- Mod --   ]
  200.  
  201. ------------------------------
  202.  
  203. Date: Thu, 20 Jun 85 15:43:57 EDT
  204. From: seismo!elsie!ado
  205. Subject: Section C.8 (preprocessing directives start)
  206. To: std-c@cbosgd
  207.  
  208. *       Section C.8, page 61:
  209.  
  210.                 [Preprocessing capabilities] are controlled by. . ."lines". . .
  211.                 that "begin with" a # separator character; more precisely, by
  212.                 a # token that is the first character in the source file (after
  213.                 any number of space and horizontal-tab characters) or that
  214.                 follows a new-line character (after any number of space and
  215.                 horizontal-tab characters).
  216.  
  217.         Elsewhere in the standard, vertical tabs and form feeds are allowed
  218.         as "white space"; for consistency and ease of implementation, they
  219.         should be allowed here also.  Change both references to "any number
  220.         of space and horizontal-tab characters" to "any amount of white space."
  221.  
  222. ------------------------------
  223.  
  224. Date: Thu, 20 Jun 85 15:43:57 EDT
  225. From: seismo!elsie!ado
  226. Subject: Section C.8.3 (#if and #elif)
  227. To: std-c@cbosgd
  228.  
  229. *       Section C.8.3, page 64, describing constraints on "#if" and "#elif"
  230.         directives:
  231.  
  232.                 Constant expressions were discussed in SC.4.  Additional
  233.                 restrictions apply to a constant expression that controls
  234.                 conditional inclusion:  All arithmetic is done as if the
  235.                 operands had type long int in the translation environment. . .
  236.  
  237.         I'm unclear from this as to whether
  238.                 #if 5.0
  239.         is a valid directive.  I'm also unclear as to whether "arithmetic"
  240.         includes "comparison":  does the constant expression in
  241.                 #if 0xffffffffu > 0
  242.         evaluate to one or does it evaluate to zero?
  243.  
  244.         Here's what I'd like to see (which may be different from the committee's        vision):
  245.  
  246.                 Constant expressions used in preprocessor directives must be
  247.                 integral constant expressions as discussed in SC.4, with
  248.                 additional restrictions: All arithmetic (including comparison)
  249.                 is done as if the operands had type long int in the translation
  250.                 environment. . .
  251.  
  252. ------------------------------
  253.  
  254. Date: Thu, 20 Jun 85 15:43:57 EDT
  255. From: seismo!elsie!ado
  256. Subject: Section C.8.3 (comments on preprocessor directives)
  257. To: std-c@cbosgd
  258.  
  259. *       Section C.8.3, page 65:
  260.  
  261.                 However, comments may appear anywhere on any source line,
  262.                 including on a preprocessor directive.
  263.  
  264.         and section C.8.6, page 65:
  265.  
  266.                 If there is no token between the # and the next new-line
  267.                 character, the directive has no effect.
  268.  
  269.         The first quote implies that
  270.                 
  271.                 #/* This is a comment */
  272.  
  273.         is valid; the second implies that it is not (the comment gets turned
  274.         into a white-space token which appears between the # and new-line).
  275.  
  276.         If the committee feels compelled to keep the null preprocessor
  277.         directive, either remove the first quote or change the second to:
  278.  
  279.                 If there is only white space (or nothing) between the # and
  280.                 the next new-line character, the directive has no effect.
  281.  
  282. ------------------------------
  283.  
  284. Date: Thu, 20 Jun 85 15:43:57 EDT
  285. From: seismo!elsie!ado
  286. Subject: Section C.8.3 (preprocessor directives order of checking)
  287. To: std-c@cbosgd
  288.  
  289. *       Section C.8.3, page 64:
  290.  
  291.                 Each directive's condition is checked in order.  If it
  292.                 evaluates to false(0), the program text that follows is skipped;
  293.                 directives are verified for correctness, but processed only to
  294.                 keep track of the level of nested conditionals.
  295.  
  296.         Suppose I write
  297.  
  298.                 #ifdef vax
  299.                 #define product(a, b) ((a) * (b))
  300.                 #endif
  301.                 /*...*/
  302.                 #ifdef vax
  303.                 #if product(3, 4) == 25
  304.                         printf("Inflation has set in.");
  305.                 #endif
  306.                 #endif
  307.  
  308.         I've tried to use the "product" macro only when I've defined it, but
  309.         since even skipped directives are "verified for correctness" the above
  310.         code will generate an error.
  311.  
  312.         Change the quote to:
  313.  
  314.                 Each directive's condition is checked in order.  If it
  315.                 evaluates to false(0), the program text that follows is skipped;
  316.                 directives are processed only to keep track of the level of
  317.                 nested conditionals.
  318.  
  319. ------------------------------
  320.  
  321. Date: Thu, 20 Jun 85 15:43:57 EDT
  322. From: seismo!elsie!ado
  323. Subject: Section C.8.6 ('null' preprocessor directive)
  324. To: std-c@cbosgd
  325.  
  326. *       Section C.8.6, page 65, describes a "null preprocessor directive."
  327.         Use of such directives adds no new functionality and impairs portability
  328.         to older systems.  Remove the section and all references to the null
  329.         preprocessor directive.
  330.  
  331. ------------------------------
  332.  
  333. Date: Thu, 20 Jun 85 15:43:57 EDT
  334. From: seismo!elsie!ado
  335. Subject: Section D.1.2 (external identifiers on headers)
  336. To: std-c@cbosgd
  337.  
  338. *       Section D.1.2, page 67:
  339.  
  340.                 All external identifiers declared in any of the headers are
  341.                 reserved, whether or not the associated header is included.
  342.                 All external identifiers that begin with an underscore are
  343.                 also reserved. . .An implementation may define macros whose
  344.                 names begin with two or more underscores, even if no headers
  345.                 are explicitly included.
  346.  
  347.         While "identifier reservation" has been reworded and put on a new page,
  348.         it is still one-sided.  Add something like the following:
  349.  
  350.                 Only identifiers that are declared in any of the headers or
  351.                 that begin with an underscore are reserved.  Defined macro names
  352.                 other than those defined in headers and those beginning with two
  353.                 or more underscores must be documented for each implementation.
  354.  
  355. ------------------------------
  356.  
  357. Date: Thu, 20 Jun 85 15:43:57 EDT
  358. From: seismo!elsie!ado
  359. Subject: Section D.9.5.6 ( printf arguments)
  360. To: std-c@cbosgd
  361.  
  362. *       Section D.9.5.6, page 96:
  363.  
  364.                 If any argument is or points to an aggregate (except for an
  365.                 array of characters using %s conversion or any pointer using
  366.                 %p conversion), the behavior is undefined.
  367.  
  368.         Since "sizeof (char *)", "sizeof (int *)" and "sizeof (void *)" may
  369.         not all be the same, I imagine that the behavior of at least
  370.         one of the printfs in the code
  371.  
  372.                 {
  373.                         int *   ip;
  374.                         char *  cp;
  375.  
  376.                         printf("%p%f\n", ip, 1.0);
  377.                         printf("%p%f\n", cp, 1.0);
  378.                 }
  379.  
  380.         is undefined.  Change the quote to something like:
  381.  
  382.                 If any argument is or points to an aggregate (except for an
  383.                 array of characters using %s conversion or a pointer to type
  384.                 void using %p conversion), the behavior is undefined.
  385.  
  386. ------------------------------
  387.  
  388. Date: Thu, 20 Jun 85 15:43:57 EDT
  389. From: seismo!elsie!ado
  390. Subject: volatile
  391. To: std-c@cbosgd
  392.  
  393. *       And a question:  is an explanation of the semantics (if any) of
  394.         code such as
  395.                 {
  396.                         extern int      i, j, k, l;
  397.  
  398.                         (volatile) (i = (j + k) + l);
  399.                         i = (volatile) ((j + k) + l);
  400.                         i = ((volatile) (j + k)) + l;
  401.                 }
  402.         in order?
  403.  
  404.  
  405. ------------------------------
  406.  
  407. End of mod.std.c Digest - Mon, 24 Jun 85 18:24:09 EDT
  408. ******************************
  409.